There is a concept of service-oriented architecture (SOA) for effectively utilizing software assets in constructing an enterprise system. SOA refers to a system architecture that is intended to construct a flexible enterprise system or inter-company business process execution system by constructing and organizing software components or functions in such a manner that the software components or functions match the components of a business process, making such software components or functions public on a network (referred to as “applications”), and causing them to collaborate.
A base for effectively connecting software components made public by SOA is a concept of service bus, which is typified by an enterprise service bus (ESB). In SOA, accessing software assets that are converted into services desires knowing the protocol, IP address position, or the like of the access destination from a scenario of the access source, such as enterprise system. A service bus is used to perform this.
FIG. 1 illustrates a concept of service bus. In FIG. 1, scenarios 1 and 2 are connected to a service bus 5 via a network, and applications 3 and 4 are connected to the service bus 5 via another network. In accessing the applications 3 and 4, the scenarios 1 and 2 are simply desired to access the service bus 5 using the desired protocol or data form; they do not have to know the protocol or position of the applications 3 and 4. This makes it possible to efficiently develop the scenarios 1 and 2. The service bus 5 has protocol and data conversion functions and performs these functions by performing common protocol communications within itself.
FIG. 2 is a configuration diagram of an example of a service bus system for performing network services. A service bus system 10 includes service scenario execution devices (may be referred to as “service scenarios”) 11a to 11c, a load balancer 12, service bus devices (may be referred to as “service buses”) 13-1 to 13-n, and application execution devices (may be referred to as “applications”) 14a to 14d. The service scenarios 11a to 11c are, for example, network telephone directory services, voice translation services, voice delivery services, or the like. The applications 14a to 14d are, for example, position information applications, translation applications, 3rd party call control (3PCC) applications, groupware, or the like.
In the service bus system 10, the service scenario execution devices 11a to 11c causes, through the service bus devices 13-1 to 13-n, the application execution devices 14a to 14d serving as back ends to collaborate. Thus, services are provided to user devices 15a to 15c or the like connected to the service scenario execution devices 11a to 11c. In the service bus system 10 configured as described above, about several to several thousand service bus devices 13-1 to 13-n are distributed for performance distribution, and each connection is allocated to one of the service bus devices 13-1 to 13-n by the load balancer 12.
As illustrated in FIG. 3, a single session between the service scenario 11a and the application 14a-1 may generate multiple sequences, since state transitions occur in a protocol such as session initiation protocol (SIP). That is, the first sequence is the first request from the service scenario 11a to the application 14a-1, and the service bus 13-1 is selected by the load balancer 12. The second sequence is a response from the application 14a-1 to the service scenario 11a, and the service bus 13-2 is selected by the load balancer 12. The third sequence is an additional request from the service scenario 11a to the application 14a-1, and the service bus 13-3 is selected by the load balancer 12. The fourth sequence is a response from the application 14a-1 to the service scenario 11a, and the service bus 13-4 is selected by the load balancer 12.
In sequences of the same session as described above, uniqueness of connection between a service scenario and an application have to be assured. Conventionally, to assure connection uniqueness in the same session, the service bus devices 13-1 to 13-n are provided with a common connection information database 16 and share connection information in the same session using the connection information database 16.
Specifically, when one of the service bus devices 13-1 to 13-n receives a session start request from one of the service scenario execution devices 11a to 11c, the service bus device registers connection information, that is, a session ID, device information of the service scenario that has made the request, and device information of an application that is to process the request, in the connection information database 16. Subsequently, when one of the service bus devices 13-1 to 13-n receives a response or the like from the application or when it receives a request or the like from the service scenario, the service bus device searches the connection information database 16 using the session ID of the received response or request to read the connection information. The service bus device then determines the destination service scenario or application of the response or request on the basis of this connection information.
If an additional service bus is provided, the node identifiers and positions of the existing service buses, to which the additional service bus is connected, are registered in the bus node table of the additional service bus. A bus node table refers to a table for storing the respective identifiers and positions of the service bus possessing the bus node table and adjacent service buses. The additional service bus then transmits bus node table update information to the existing service buses. Based on the bus node table update information, the existing service buses register the node identifier and position of the additional service bus in their bus node tables. Technologies that can cause multiple service buses to collaborate, as described above, have been proposed (for example, see Japanese Laid-open Patent Publication No. 2010-9218).
On the other hand, in response to a connection request for a new session from a client, a destination server allocates a session identifier to the new session. The destination server then stores the session identifier in a priority information storage unit in such a manner that the session identifier is associated with priority information and communication quality corresponding to the priority information. When a transfer unit receives a packet from the client or server, it transfers the packet with the communication quality corresponding to the priority information. This makes it possible to perform priority control on clients corresponding to the desire of a service provider. Such technologies have been proposed (for example, see Japanese Laid-open Patent Publication No. 2003-152783).